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ABSTRACT 



Data is protected using locks, with the protected data some- 
times being included in the locking messages, which may 
reduce overall processing latency, and/or reduce a bandwidth 
requirement for and/or number of storage operations access- 
ing the native storage of the protected data. For example, the 
lock manager receives lock requests from each of the request- 
ers, and selectively grants the lock requests. The protected 
data is typically communicated in the locking messages when 
the lock is highly contested, or at least two request for access 
to the data are pending. The lock manager initiates the 
sequence by indicating in a grant message to a requester to 
include the protected data in its release message. The lock 
manager then copies this data received in the release message 
tH- to its grant message to the nex (requestorJ f no other request- 
ers are waiting, the grant message includ es an indication not 
to send the protected data, and thus the Lrequestoj 'typically 
stores thisprotecteddata to storage so it can be accessed in the 
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BYPASSING NATIVE STORAGE 
OPERATIONS BY COMMUNICATING 
PROTECTED DATA WITHIN LOCKING 
MESSAGES USING A LOCK MANAGER 
INDEPENDENT OF THE STORAGE 
MECHANISM 

TECHNICAL FIELD 

One embodiment of the invention relates to communica- 
tions and computer systems employing locking mechanisms 
to protect (lata: particularly, one embodiment relates to com- 
municating protected data within locking messages; and 
more particularly, one embodiment relates to bypassing 
native storage by communicating protected data within lock- 
ing messages with a lock manager independent of the storage 
mechanism. 

BACKGROUND 



inicating protected data within locking m 
is protected using locks, with the protected data sc _. 
being included in the locking messages, which may reduce 
overall processing latency, and/or reduce a bandwidth 
requirement for and/or number of storage operations access- 
ing the native storage of the protected data. For example, in 
one embodiment, the lock manager receives lock requests 
from each of the requesters, and selectively grants the lock 
requests. The protected data is typically communicated in the 
3 locking messages when the lock is highly contested, or at 
least two request for access to the data are pending. The lock 
manager initiates the sequence by indicating in a grant mes- 
sage to a requester to include the protected data in its release 
message. The lock manager then copies this data r eceived ir 



In many multiprocessor environments, iuler-processor " 
communication is provided through shared global memory. 
Access to this memory is generally protected through locks. 
The latency for access to these resources is coupled through 
the critical section of code and includes acquiring the lock, 
reading the data, writing the data, and finally releasing the 25 
lock. Note, nothing described or referenced in this document 
'•- '"i'ji'l'L'd as prior art to this application unless explicitly so 

One such prior approach is illustrated in FIG. 1, which 
shows how three requesters request and gain access to pro- 30 
tected data. Note, as shown in FIG. 1, the lock manager is 
independent of the storage mechanism as it does not access 
the lock protected data from its native storage. In fact, the lock 
manager of FIG. 1 never communicates nor otherwise pro- 
cesses a value of the protected data. 35 

As shown, each requester sends a request to the lock man- 
ager, which provides independent access to the protected data 
by sending a grant message to one of the requesters. The 
granted requester then reads the protected data, performs its 
processing, writes the protected data back to memory, and 40 
then sends a release request to the lock manager to indicate 
that it is done with the protected data. This process repeats and 
a next requester is granted access to the data. Thus, there can 
be significant amount of latency that is exposed in the critical 
section of code, especially when multiple processors are 45 
queued up behind a single locking queue. The significant 
amount of latency is also true of processors that rely on 
caching within the processor units to provide temporary stor- 
age as well as provide direct inter-processor communication 
to transfer data. ' 50 

Also, one know n system includes a lock manager in an LO 
subsystem which allows a message to include both locking 
and data storage requests. "Hits allows a requester proxy pro- 
cess m the ! 11 subsystem to receive a message with both a 
lock request and an I/O request. In response, this proxy pro- 55 
cess makes a request to the lock manager lor the lock, and in 
response to a grant, it then makes the corresponding I/O 
request corresponding to the 1 O request and its native\stor- 
age. Tins approach may reduce some messages and latency 
when the protected data is located in another subsystem, but 60 
in response to each grant, the I/O native storage is still 



. inter alia, methods, apparatus, data struc- 
readable media, mechanisms, and means for 



the release message to its grant message to the nextfrequestorT" 
Although this operation may require the lock manager to 
temporarily store the received release message including the 
protected data, it does not cache or otherwise store the pro- 
tected data locally awaiting the receipt of a next request, for 
example. If no other requesters are waiting, the grant message 
includes an indication not to send the protected data, and thus 
the requester typically stores this protected data to storage so 
it can be accessed in the future. 

One embodiment includes a lock manager configured to 
control access via a lock to protected data maintained in 
native storage independent of the lock manager. The lock 
manager does not access the protected data from the native 
storage, rather it copies the protected data received into grant 
messages sent to a next requester. The lock manager is con- 
figured to receive lock requests for the lock from multiple 
requesters, and to selectively grant the lock requests which 
includes communicating grants from the lock manager to the 
plurality of requesters, wherein at least one of the communi- 
cated grants includes the protected data. 

In one embodiment, wherein at least one of the communi- 
cated grants does not include the protected data. In one 
embodiment, each of the communicated grants includes an 
indication of whether or not the protected data is being com- 
municated therewith. In one embodiment, each of the com- 
municated grants includes an indication of whether or not the 
protected data is requested to be sent to the lock manager with 
a corresponding release of the lock. In one embodiment, each 
of the lock requests includes an indication of whether or not 
the corresponding one of the plurality of requesters will 
accept the protected data from the lock manager. 

One embodiment includes a lock manager that controls 
access to protected data maintained in native storage inde- 
pendent of the lock manager, wherein the lock manager does 
not access the protected data from the native storage. The lock 
manager receives a release of a lock for use in controlling 
access to the protected data, with the received release includ- 
ing the protected data. A next requester to be granted the lock 
is identified in response to the receiving the release of the 
lock. The protected data is copied from the release into a grant 
message, and the grant message including the protected data 
is sent to the next requester. In one embodiment, the grant 
message includes an indication of that the protected data is 
requested to be sent to the lock manager in a release message 
corresponding to the grant message if another requester is 
waiting for the lock, else an indication that the protected data 
is not requested to be sent to the lock manager in the release 
message. 

One embodiment includes a lock manager that controls 
access to protected data maintained in native storage inde- 
pendent of the lock manager, wherein the lock manager does 
not access the protected data from the native storage. The lock 
manager receives locking requests for a lock controlling 
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access to the protected data from a first requester and a second 
requester. The lock manager sends a first grant message not 



embodiments described hereinafter embody various aspects 
and configurations within the scope and spirit of the inven- 
tion, with the figures illustrating exemplary and non-limiting 
configurations. 

As used herein, the term "packet" refers to packets of all 
types or any other units of information or data, including, but 
not limited to, fixed length cells and variable length packets, 
each of which may or may not be divisible into smaller 
packets or cells. The term "packet" as used herein also refers 
l to both the packet itself or a packet indication, such as, but not 
limited to all or part of a packet or packet header, a data 
structure value, pointer or index, or any other part or direct or 
indirect identification of a packet or information associated 
therewith. For example, often times a router operates on one 
s or more fields of a packet, especially the header, so the body 
of the packet is often stored in a separate memory while the 
in indication not to send the protected data packet header is manipulated, and based on the results of the 
■ message in response to identifying processing of the packet (i.e., the packet header in this 
it waiting for access to the lock. In one example), the entire packet is forwarded or dropped, etc 
e second grant message includes an indica- 20 Additionally, these packets may contain one or more types of 
tton not to send the protected data in the second release information, including, but not limited to, voice, data video 
message and in response to the indication not to send the and audio information. The term "item" is used genetically 
protected data in the second release message, the second herein to refer to a packet or any other unit or piece of 
requester stores the protected data and does not include the information or data, a device, component, element or any 
protected data in the second release message. 25 other entity. The phrases "processing a packet" and "packet 

processing" typically refer to performing some steps c 



including the protected data to the first requester, and 
response to identifying one or more requesters is waiting for 
the lock after the first requester, an indication to return the 5 
protected data is included in the grant message. A first release 
message including the protected data for the lock is subse- 
quently received from the first requester. 

In one embodiment, a second grant message is sent to the 
second requester, with the second grant message including 
the protected data and an indication of whether or not to send 
the protected data in a second release message. In one 
embodiment, the second grant message includes an indica- 
tion to send the protec ted data in the second r eleasp message 
in response to identifying anothe j requestor' s waiting for 15 
access to the lock. In one embodiment, the second grant 



BRIEF DESCRIPTION OF THE DRAWINGS 

The appended claims set forth the features of the invention 
with particularity. The invention, together with its advan- 
tages, may be best understood from the following detailed 
description taken in conjunction with the accompanying 
drawings of which: 

1 j ( < 1 illustrates a prior approach for usinga lock to protect 

FIG. 2. illustrates an approach used in one embodiment for 
protecting access to data with the protected data being com- 
municated in conjunction with locking messages; 

FIG. 3 illustrates locking messages used in one embodi- 



FIGS.4A-H illustrate lock 
embodiment: 

FIG. 4C illustrates a requester process used in one embodi- 
ment; and 

FIG. 5A illustrates a system including a lock manager and 
multiple requesters of one embodiment: and 

FIG. 5IJ illustrate a system or component used in one 
embodiment for implementing a lock manager and/or one or 

more requesters. 

DETAILED DESCRIPTION 

Disclosed are. inter alia, methods, apparatus, data struc- 
tures, computer-readable media, mechanisms, and means lor 
communicating protected data within locking messages. 

Embodiments described herein include various elements 
and limitations, with no one element or limitation contem- 
plated as being a critical element or limitation. Each of the 
claims individually recites an aspect of the invention in its 
entirety. Moreover, some embodiments described may 
include, but are not limited to, inter alia, systems, networks, 
integrated circuit chips, embedded processors, ASICs, meth- 
ods, and computer-readable media containing instructions. 
One or multiple systems, devices, components, etc. may com- 
prise one or more embodiments, which may include some 
elements or limitations of a claim being performed by the 
same or different systems, devices, components, etc. The 



actions based on the packet contents (e.g., packet header o: 
other fields), and such steps or action may or may not include 
modifying, storing, dropping, and/or forwarding the packet 
30 and/or associated data. 

The term "system" is used genetically herein to describe 
any number of components, elements, sub-systems, devices, 
packet switch elements, packet switches, routers, networks^ 
computer and/or communication devices or mechanisms, or 
35 combinations of components thereof. The term "computer" is 
used generically herein to describe any number of computers, 
including, but not limited to personal computers, embedded 
processing elements and systems, control logic, ASICs, 
chips, workstations, mainframes, etc. The term "processing 
40 element" is used generically herein to describe any type of 
processing mechanism or device, such as a processor, ASIC, 
field programmable gate array, computer, etc. The term 
"device" is used generically herein to describe any type of 
mechanism, including a computer or system or component 
45 thereof. The terms "task" and "process" are used generically 
herein to describe any type of running program, including, but 
not limited to a computer process, task, thread, executing 
application, operating system, user process, device driver, 
native code, machine or other language, etc., and can be 
50 interactive and/or non-interactive, executing locally and/or 
remotely, executing in foreground and/or background, 
executing in the user and/or operating system address spaces, 
a routine of a library and/or standalone application, and is not 
limited to any particular memory partitioning technique. The 
55 steps, connections, and processing of signals and information 
illustrated in the figures, including, but not limited to any 
block and flow diagrams and message sequence charts, may 
typically be performed in the same or in a different serial or 
parallel ordering and/or by different components and/or pro- 
60 cesses, threads, etc. , and/or over different connections and be 
combined with other functions in other embodiments, unless 
this disables the embodiment or a sequence is explicitly or 
implicitly required (e.g., for a sequence of read the value, 
process the value— the value must be obtained prior to pro- 
65 cessing it, although some of the associated processing may be 
performed prior to, concurrently with, and/or after the read 
operation). Furthermore, the term "identify" is used generi- 
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cally to describe any manner or mechanism for directly or 
indirectly .is.vvr!;iia::ig something, which may include, but is 
not limited to receiving, retrieving from memory, determin- 
ing, defining, calculating, generating, etc. 

Moreover, the terms "network" and "communications 5 
mechanism" arc used generic-ally herein to describe one or 
more networks, communications media or communications 
systems, including, but not limited to the Internet, private or 
public telephone, cellular, wireless, satellite, cable, local area, 
metropolitan area and/or wide area networks, a cable, elec- 10 
iric.il connection, bus. etc.. and internal communications 
mechanisms such as message passing, interprocess commu- 
nications, shared memory, etc. 

1'he term "message" is used generically herein to describe 
a piece oi" information winch may or may not be, but is 15 
typically communicated via one or more communication 
mechanism,-, of any type. 

Hie term "'storage mechanism" includes any type of 
memory, storage device or other mechanism for maintaining 
instructions or data in any format. "Computer-readable 20 
medium" is an extensible term including any memory, stor- 
age dev ice, storage mechanism, and other storage and signal- 
ing mechanisms including interfaces and devices such as 
network interface cards and buffers therein, as well as any 
communications devices and signals received and transmit- 25 
ted. and other current and evolving technologies that a com- 
puterized system can interpret, receive, and/or transmit. The 
term "memory " includes any randomaccess memory (RAM), 
read only memory (ROM ), flash memory, integrated circuits, 
and.- or oilier memory components or elements. The term 30 
"storage dc\ ice" includes any solid stale storage media, disk 
drives, diskettes, networked services, tape drives, and other 
storage devices. Memories and storage devices may store 
computer-executable instructions to be executed by a pro- 
cessing element and/or control logic, and data which is 35 
manipulated by a processing element and/or control logic. 
The term "data structure" is an extensible term referring to 
any data element, variable, data structure, database, and/or 
one or more organizational schemes that can be applied to 
Jala to facilitate interpreting the data or performing opera- 40 
tions on it, such as. but not limited to memory locations or 
devices, sets, queues, trees, heaps, lists, linked lists, arrays, 
tables, pointers, etc. A data structure is typically maintained 
in a storage mechanism. The terms "pointer" and "link" arc- 
used generically herein to identify some mechanism for rcf- 45 
erencingor identifying another element, component, or other 
entity, and these may include, but are not limited to a refer- 
ence to a memory or other storage mechanism or location 
therein, an index in a data structure, a value, etc. 

The term "one embodiment" is used herein to reference a 50 
particular embodiment, wherein each reference to "one- 
embodiment" may refer to a different embodiment, and the 
use of the term repeatedly herein in describing associated 
team res. elements and/or limitations does not establish a 
cumulative set of associated features, elements and/or limi- 55 
unions that each and every embodiment must include, 
although an embodiment typically may include all these fea- 
tures, elements and. or limitations. In addition, the phrase 
"means for xxx" typically includes computer-readable media 
containing computer-executable instructions for performing 6n 



In addition, the terms "first," "second," etc. are typically 
used herein to denote different units (e.g., a first element, a 
second element). The use of these terms herein does not 

occurring or coming before another, but rather provides a 
mechanism to distinguish between particular units. Addition- 



oun is non-limiting, with 
>re of the particular thing 
of the word "memory" 
without having to 



ally, the use of a singular tense of 
its use typically including one or 
rather than just one (e.g., the u 
typically refers to one or more 
specify "memory or memories,' 

or "at least one memory", etc.). Moreover, the phrases "based 
on x" and "in response to x" are used to indicate a minimum 
set of items x from which something is derived or caused, 
wherein "x" is extensible and does not necessarily describe a 
complete list of items on which the operation is performed, 
etc. Additionally, the phrase "coupled to" is used to indicate 
some level of direct or indirect connection between two ele- 
ments or devices, with the coupling device or devices modi- 
fying or not modifying the coupled signal or communicated 
information. The term "subset" is used to indicate a group of 
all or less than all of the elements of a set. The term "subtree" 
is used to indicate all or less than all of a tree. Moreover, the 
term "or" i s u sed herein to identify a selection of one or more, 
including all, of the conjunctive items. 

Locks can be used for many purposes. For example, one 
application of locks is described in Williams et al., "Using 
Ordered Locking Mechanisms to Maintain Sequences of 
Items Such as Packets," U.S. patent application Ser. No. 
10/706,704, filed Nov. 12, 2003, which is hereby incorpo- 
rated by reference. 

Disclosed are, inter alia, methods, apparatus, data struc- 
tures, computer-readable media, mechanisms, and means for 
communicating protected data within locking messages. Data 
is protected using locks, with the protected data sometimes 
being included in the locking messages, which may reduce 
overall processing latency, and/or reduce a bandwidth 
requirement for and/or number of storage operations access- 
ing the native storage of the protected data. For example, in 
one embodiment, the lock manager receives lock requests 
from each of the requesters, and selectively grants the lock 
requests. The protected data is typically communicated in the 
locking messages when the lock is highly contested, or at 
least two request for access to the data are pending. The lock 
manager initiates the sequence by indicating in a grant mes- 
sage to a requester to include the protected data in its release 
message. The lock manager then copies this data received in 
the release message to its grant message to the nexJrequestor.'] 
Although this operation may require the lock manager to v/ 
temporarily store the received release message including the " K* 60UCS"t;e(~ U 
protected data, it does not cache or otherwise store the pro- yf. "K 
tected data locally awaiting the receipt of a next request, for ^ 
example. If no other requesters are waiting, the grant message 
inc ludes an indication not to send the protected data, and thus 
th ^requestorft ypically-sTores this protected data to storage" 
it can be accessed in the future. 

One embodiment includes a lock manager configured to 
control access via a lock to protected data maintained in 
native storage independent of the lock manager. The lock 
manager does not access the protected data from the native 
storage, rather it copies the protected data received into grant 
messages sent to a next requester. The lock manager is con- 
figured to receive lock requests for the lock from multiple 
requesters, and to selectively grant the lock requests which 
includes communicating grants from the lock manager to the 
plurality of requesters, with at least one of the communicated 
grants includes the protected data. 

In one embodiment, at least one of the communicated 
grants does not include the protected data. In one embodi- 
ment, each of the communicated grants includes an indication 
of whether or not the protected data is being communicated 
therewith. In one embodiment, each of the communicated 
grants includes an indication of whether or not the protected 
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data is requested to be sent to the lock manager with a corre- 
sponding release of the lock. In one embodiment, each of the 
lock requests includes an indication of whether or not the 
corresponding one of the plurality of requesters will accept 
the protected data from the lock manager. 

One embodiment includes a lock manager that controls 
access to protected data maintained in native storage inde- 
pendent of the lock manager. The lock manager does not 
access the protected data from the native storage. The lock 
manager receives a release of a lock for use in controlling 1 
access to the protected data, with the received release includ- 
ing the protected data. A next requester to be granted the lock 
is identified in response to the receiving the release of the 
lock. The protected data is copied from file release into a grant 
message, and the grant message including the protected data 1 
is sent to the next requester. In one embodiment, the grant 
message includes an indication of that the protected data is 
requested to be sent to the lock manager in a release message 
corresponding to the grant message if another requester is 
waiting for the lock, else an indication that the protected data 2 
is not requested to be sent to the lock manager in the release 
message. 

One embodiment includes a lock manager that controls 
access to protected data maintained in native storage inde- 
pendent of the lock manager. The lock manager does not 2 
access the protected data from the native storage. The lock 
manager receives locking requests for a lock controlling 
access to the protected data from a first requester and a second 
requester. The lock manager sends a first grant message not 
including the protected data to the first requester, and in 
response to identifying one or more requesters is waiting for 
the lock alter the first requester, an indication to return the 
protected data is included in the grant message. A first release 
message including the protected data for the lock is subse- 
quently received from the first requester. 

In one embodiment, a second grant message is sent to the 
second requester, with the second grant message including 
the protected data and an indication of whether or not to send 
the protected data in a second release message. In one 4 
embodiment, the second grant message includes an indica- 
tion to send the protected data in the second release message 
in response to identifying another requester is waiting for 
access to the lock. In one embodiment, the second grant 
message includes an indication not to send the protected data 4 
' message in response to identifying 
nVequestorj is not waiting for access to the lock. In" one 
embodiment, the second grant message includes an indica- 
tion not to send the protected data in the second release 
message, and in response to the indication not to send the 5 , 
protected data in the second release message, the second 
requester stores the protected data and does not include the 
protected data in the second release message. 

One embodiment provides an indirect interprocess com- 
munication bypass channel through a lock mechanism that is 5. 
connected to many processors. These processors normally 
communicate through shared global memory and use locks to 
enforce coherency. Under certain conditions, data can be 
transferred through lock messages instead of going through 
shared global memory. The data can be piggy-backed to the 6i 
lock release message, go through the lock mechanism, and be 
piggy-backed to the lock grant message. The data is not stored 
for any significant amount of time in the lock mechanism. The 
lock messages typically include control signals to indicate 
when the conditions are right to use the bypass channel. This 6. 
enforces the coherency of the shared memory location that 
might be bypassed. 



When claiming to piggy -back the data to the lock message, 
the bypass channel could be either serial or parallel to the lock 
message channel, as long as there is a strong binding of lock 
messages to bypass data. In one embodiment, when request- 
ing a lock, the request message includes an indication if it is 
willing to accept data through the bypass channel. When the 
lock is finally granted, the grant message indicates if it has 
data in the bypass channel, and if there is an entry following 
it in the locking queue that is willing to accept data through 
the bypass channel. If the grant indicates that data is present 
in the bypass channel, then the critical section can skip the 
read of the global shared memory location and use the data 
from the bypass channel instead. 

If the grant indicates that the next entry in the locking 
queue is willing to accept data from the bypass channel, then 
the critical section of code can skip the write of the global 
shared memory location and send the data through the bypass 
channel instead. The critical section of code can always send 
the data through the bypass channel with the hope that a new 
arrival in the locking queue can use the data, but it must first 
commit the write to global shared memory if it is not certain. 
When the lock is released, an indication is made in the release 
message whether the bypass channel has data in it or not. The 
data in the bypass channel is typically not stored in memory in 
the lock mechanism; rather it is simply copied (possibly using 
a temporary storage location or register) from the release 
message and attached to the subsequent grant message. 

Turning to the figures, FIG. 2. illustrates an approach used 
in one embodiment for protecting access to data with the 
protected data being communicated in conjunction with lock- 
ing messages. Lock manager 200 receives locking requests 
211-213 from requester-A 204, requester-B 206, and 
requester-C 208. Note, lock manager 200 is independent of 
the storage mechanism/protected data 202 as it does not 
access stored lock protected data 202 from its native storage 
as depicted in FIG. 2. 

An example of such a locking request is locking request 
message 300 illustrated in FIG. 3. As shown, request message 
300 includes an indication 301 of which lock is being 
requested, an identification 302 of the requester, and an indi- 
cation 303 of whether the requester supports protected data in 
locking messages. Of course, one embodiment uses another 
communication mechanism and/or some, all, or none of val- 
ues 301-303. Also, the number of bits illustrated for certain 
fields arc only exemplary of one embodiment. 

For purposes of illustration, the description of FIG. 2 will 
assume that all requesters will always support protected data 
in locking messages (and thus indication 303 is not required). 
In one embodiment when all requesters do not always support 
protected data being communicated in locking messages, 
locking manager 200 will only request protected data when 
the next requester supports such, and provide protected data 
in a locking message to a supporting requester. 

Also shown in FIG. 3, is a grant message 310 used in one 
embodiment, and release message 320 used in one embodi- 
ment. As shown, grant message 3 10 includes a lock indication 
311 identifying the lock, a field 312 for including protected 
data, an indication 313 of whether or not field 312 is popu- 
lated with the protected data, and an indication 314 of 
whether or not an explicit request to bypass native storage for 
the protected data is being made. 

In one embodiment, if the native storage bypass request 
indication is set, the requester must return the latest value of 
the protected data in a corresponding release message, and the 
requester may or may not store the protected data in its native 
storage prior to sending the release (i.e., the value of the 
protected data in the native storage may or may not be the 
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block 4s8. the protected data is retrieved from storage, and invention. For example and as would be apparent to one 
processing is P erl, .nned bused on the retrieved protected data. skilled in the art, many of the process block operations can be 
Alter processing oi the protected data is complete, then, as re-ordered to be performed before, after, or substantially con- 
ten ,c, 1 ,n process 1 loc k 460. , 1 the received grant indi- current with other operations. Also, many different forms of 
caled Unit native storage is to he bypassed, then processing 5 data structures could be used in various embodiments The 
proceeds to process block 468. Otherwise, in process block invention as described herein contemplates all such embodi- 
462. the latest value of the protected data is stored in its native ments as may come within the scope of the following claims 
storage location As determined in process block 464, if the and equivalents thereof, 
protected data is to be included in the release (e.g., it is alwavs . 
included, or optionalb ncluded 1 ed , s determina- to What ,s claimed is: 

turn), then processing proceeds to process block 468 Other- ' a PP ararus for protecting data using locks, the appa- 
wise, in process block 466. the release message is sent to the ? ^ ^ om P rlsln g : one or more processors and memory, con- 
lock manager without the protected data. In process block 8 , , t0 mc!l,de: 

468, a release message includi. . the 1 h 1 value of the pro- 3 lock man fB er configured to control access via a lock to 

tected data is sent to the lock manager. Processing is complete 1 5 protected data maintained m native storage independent 

as indicated by process block 469. ol me lock manager, wherein the lock manager does not 

IK, 5A illustrates;, system including a lock manager 501 access said protected data from said native storage; and 

andmultiplerequesters5n-5J9ofoneembodiment.FIG.5A a plurality of requesters; 

shows the extensible nature of one embodiment of the inven- wherein the lock manager is configured to receive lock 

tion which can be applied to an application. Lock manager 20 requests for the lock from each of the plurality of 

50 1 and multiple requesters 51 1 -519 can be processes, sepa- requesters, and to selectively grant said lock requests 

rate processing elements, or any other processing mechanism Wmch lncludes communicating grants from the lock 

orentity in one or more systems, elements, or components. As manager to the plurality of requesters, wherein at least 

shown, lock manager 501 is communicatively coupled via oneoi said communicated grants includes said protected 

communications mechanism 509 with multiple requesters 25 ^ rcccivcd in a corresponding release of the lock 

511-519, which are also communicatively coupled to the messageJrma4gg vious holder of the lock of the plu- 



mechanism 502 lor storing the protected data and/or other raiity of l re ^ uestor! - 

2. The apparatus of claim 1, wherein at least one of said 



FIG. SB illustrate a system or component used in one communicated grants does not include said protected data, 

embodiment for implementing a lock manager and/or one or 30 3 ' rhe apparatus of claim 1, wherein each of said commu- 

more requesters. In one embodiment, system or component nic ated grants includes an indication of whether or not said 

54(1 performs one or more processes corresponding to one of protected data is being communicated therewith, 

the flow diagrams illustrated or otherwise described herein. 4 - ^ apparatus of claim 1, wherein each of said commu- 

For example, in one embodiment, the lock manager and nic ated grants includes an indication of whether or not said 

requesters are processes running on processing element 541, 35 protected data is requested to be sent to the lock manager with 

and memory 542 is used for storing the protected data when it a corresponding release of the lock. 

is not communicated via locking messages. 5. The apparatus of claim 1, wherein each of said lock 

In one embodiment, system or component 540 includes a requests includes an indication of whether or not the corre- 

pmcessing element 541, memory 542, storage devices 543, sponding one of the plurality of requesters will accept said 

and an interface 544 for sending and receiving packets, items, 40 protected data from the lock manager, 

and/or other information, which are typically coupled via one 6 A method performed by a lock manager controlling 

or more communications mechanisms 549 (shown as a bus access to protected data maintained in native storage inde- 

l'or illustrative purposes.) Various embodiments of compo- pendent of the lock manager, wherein the lock manager does 

nent 540 may include more or less elements. The operation of not access said protected data from said native storage, the 

component 540 is typically controlled by processing element 45 method comprising: 

541 using memory 542 and storage devices 543 to perform receiving a release of a lock for use in controlling access to 

one or more tasks or processes. Memory 542 is one type of sa id protected data, the release including said protected 

computer-readable media, and typically comprises random data; 

access memory (RAM), read only memory (ROM), flash identifying a next requester to be granted the lock in 

memory, integrated circuits, and/or other memory compo- 50 response to said receiving the release of the lock; 

nents. Memory 542 typically stores computer-executable copying said protected data from the release into a grant 

instructions to be executed by processing element 541 and/or message; and 

data which is manipulated by processing element 541 for sending the grant message to the next requester, the grant 

implementing lunciionality in accordance with an embodi- message including said protected data 

mem. Storage devices 543 are another type of computer- 55 7. The method of claim 6, wherein the grant message 

and 'yP'C'lly comprise solid slate slorage includes an indication of that said protected data is requested 

media disk drives, diskettes, networked services, tape drives. to be sent to the lock manager in a release message corre- 

1 1 ' 1 lev ice 543 typically store spending to the grant message if another requester is waiting 

compute. -executah c instructions to be executed by process- for the lock, else an indication that said protected data is not 

mg element 541 an ». 1 , lucl , manipulated by process- 60 requested to be sent to the lock manager in the release mes- 

ing element 541 lor implementing functionality in accor- sage. 

ll "tn^ ;l " ™ lhodlmenl 8. A tangible computer-readable medium storing thereon 

111 V1 , cw 7 thc raan >' P 11 embodiments to which the computer-executable instructions for performing steps by a 

principles o our invention may be applied, it will be appre- lock manager for controlling access to protected data main- 

l ' t ' ' ' ' " emb ; ,dl ' lle " / 1 ' f described « tamed in native storage independent of the lock manager, 

he, cm vv ith respect to the drawings/figures are only illustra- wherein the lock manager does not access said protected data 

live and should not be taken as limiting the scope of the from said native storage, said steps comprising- 
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receiving a release of a lock for use in controlling access to 
said protected data, the release including said protected 

identifying a next requester to be granted the lock in 

response to said receiving the release of the lock; 
copying said protected data from the release into a grant 

sending the grant message to the next requester, the grant 
message including said protected data. 

9. 1 he coinpnlei -readable medium of claim 8. wherein the 1 
grant message includes an indication of that said protected 
data is requested to he sent to the lock manager in a release 
message corresponding to the gram message if another 
requester is wailing lor the lock, else an indication that said 
protected data is not requested to be sent to the lock manager ' 
in the release message. 

10. A lock manager controlling access to protected data 
maintained in native storage independent of the lock man- 
ager, wherein the lock manager docs not access said protected 
data from said native storage, the lock manager comprising: ~< 

means for receiving a release of a lock for use in controlling 

access to said protected data, the release including said 

protected data; 
means for identifying a next requester to be granted the 

lock in response to said receiving the release of the lock; : 
means for copying said protected data from the release into 

a grant message and for sending the grant message to the 

next requester. 

11 . The lock manager of claim 10, means for including in 
the grant message an indication of that said protected data is 2 
requested lo be sent lo the lock manager in a release message 
corresponding to the grant message if another requester is 
waiting for the lock, else an indication that said protected data 
is not requested to be sent to the lock manager in the release 
message. 2 

12. A method performed by a lock manager controlling 
access to protected data maintained in native storage inde- 
pendent of the lock manager, wherein the lock manager does 
not access said protected data from said native storage, the 
method comprising: 4 

receiving locking requests for a lock controlling access to 
said protected data from a first requester and a second 
requester; 

sending a first grant message lo the first requester, the first 
grant message not including said protected data, and in 45 
response to identifying one or more requesters is w aiting 
for Ihe lock alter the first requester, including an indica- 
tion to return said protected data in the first grant mes- 
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first release message corresponding to the first 
;ssage for the lock from the first requester, the 
' icluding said protected data and 



the 



■ndinga second grant message to the secondfr equesto r^ 
ie second grant message including said protected data - 



11 «>«iiP<ik»r" """ ° tcullJ & aat message including said protected data , 
IC^OCCTCC-* received in the first release message. 

13. The method of claim 12, wherein the second grant 
message includes an indication o ("whether or not to send said 
protected data in a second release message. 

14. I he method of claim 13. wherein the second grant t 
'• message includes an indication to send said protected data in 
\ me sec ond release message in response to identifying another 

, I request o7K waiting for access to the lode. 

15. The method of claim 13. wherein the second grant 
\ message inch n ndii ttion not to send said protected data < 
v — UL_the_second release message in response to identifying 

another jrequestorj is not waiting for access to the lock. 



16. The method of claim 13, wherein the second grant 
message includes an indication not to send said protected data 
in the second release message; and the method comprises in 
response to said indication not to send said protected data in 
the second release message, the second requester storing said 
protected data and not including said protected data in the 
second release message. 

17. A tangible computer-readable medium storing thereon 
o computer-executable instructions for performing steps by a 

lock manager for controlling access to protected data main- 
tained in native storage independent of the lock manager, 
wherein the lock manager does not access said protected data 
s from said native storage, said steps comprising: 

receiving locking requests for a lock controlling access to 
said protected data from a first requester and a second 
requester; 

sending a first grant message to the first requester, the first 
J grant message not including said protected data, and in 
response to identifying one or more requesters is waiting 
for the lock after the first requester, including an indica- 
tion to return said protected data in the first grant mes- 
5 sage; 

receiving a first release message corresponding to the first 
grant message for the lock from the first requester, the 
first release message including said protected data; and 
sending a second grant message to the second requester, 
the second grant message including said protected data 
received in the first release message. 

18. The computer-readable medium of claim 17, wherein 
the second grant message includes an indication of whether or 

5 not to send said protected data in a second release message. 

19. The computer-readable medium of claim 18, wherein 
die second grant message includes an indication to send said 
protected data in t he second relea se message in response to 

5 identifying anothettec * "' 



'aiting lor access to the lock. 

20. The computer-readable medium of claim 18, wherein 
the second grant message includes an indication not to send 
said protected data in the second release message in response 
to identifying another (requestor) s not waiting lor access to~ 
the lock. 

21. The computer-readable medium of claim 18, wherein 
the second grant message includes an indication not to send 
said protected data in the second release message; and said 
steps comprise in response to said indication not to send said 
protected data in the second release message, the second 
requester storing said protected data and not including said 
protected data in the second release message. 

22. A lock manager controlling access to protected data 
maintained in native storage independent of the lock man- 
ager, wherein the lock manager does not access said protected 
data from said native storage, the lock manager comprising: 

means for receiving locking requests for a lock controlling 
access to said protected data from a first requester and a 
second requester; 

means for sending a first grant message to the first 
requester, the first grant message not including said pro- 
tected data, and in response to identifying one or more 
requesters is waiting for the lock after the first requester, 
including an indication to return said protected data in 
the first grant message; 
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means for receiving a first release message for the lock 
from the first requester, the first release message includ- 
ing said protected data; and means for sending a second 
grant message to the second requester, the second grant 
message including said protected data received in the 5 access 
iirsl release message. 

23. The lock manager of claim 22, wherein the second 
grant message includes an indication of whether ornot to send 
said protected data in a second release message. 

24. The lock manager of claim 23. comprising means for 
including in the second grant message an indication to send 
said prot ected data in t h e second. r elease message in response 
to identifying" aT^ther/rcqiiestoris wailing lor access to the 



25. The lock manager of claim 23, comprising means for 
including in the second grant message an indication not to 



.-. protected data in t he second release n,^.,.,.,> u . 
response to identifying another ) requestor' s not waiting for ' 



the lock. 

26. The lock manager of claim 23, comprising: means for f 
including in the second grant message an indication not to 
send said protected data in the second release message; and 
means for the second requester to store said protected data 
and not to include said protected data in the second release 
message in response to said indication not to send said pro- 
tected data in the second release m 



